The present invention relates to methods and apparatus for processing data within a computer network. More specifically, it relates to handling requests for data, such as web pages, from a private network, such a virtual private network (VPN).
FIG. 1 is a diagrammatic representation of a network 100 having a secure socket layer (SSL) enabled HTTP server 108 which is accessible by one or more clients. In one example, the SSL enabled HTTP server 108 is a commercial bank's customer server located within its banking network 106. A client 102 may access data from SSL enabled HTTP server 110 through a secure SSL connection. In the banking example, a bank customer may access account information from the SSL enabled HTTP server of his/her banking network using his home personal computer (PC). The client can typically access data within the private network through a connection device, such as a dial-up modem, DSL, cable modem, etc. The client generally uses a web browser to establish a connection with a SSL enabled HTTP server.
In the banking example, banking customer 102 inputs the URL www.mybank.com via their web browser. The URL www.mybank.com is resolved to the address of the SSL enabled HTTP server 108 of the client's banking network 106. When the request for the initial web page is sent to the SSL enabled HTTP server 108, the SSL enabled HTTP server negotiates a secure protocol (e.g., the client is authenticated and encryption is used for the message sent thereafter on the connection) with the client and then presents an initial web page to the client 102. The SSL enabled HTTP server 108 may also be configured to perform a secure setup, e.g., via a log in procedure, with client 102. In the banking case, the customer client 102 may click on a “logon” link on the initial web page to begin the secure setup process, where a user name and password is authenticated by the SSL enabled HTTP server 108.
This server arrangement provides a secure connection between a server and a client. However, this SSL enabled HTTP server arrangement has disadvantages. For instance, the client can only access data or information on servers which are configured to negotiate an SSL connection. Also, if a particular SSL enabled HTTP server becomes overloaded with information, another server must be configured as an SSL enabled HTTP server.
FIG. 2 is a diagrammatic representation of a network 200 which includes an IPSec Server 208 which is configured to set up a tunnel with a client 202 so that the client may access other internal servers. Each client 202 which wishes to access data in the private network 206 of the IPSec server 208 must be configured with an IPSec client which can communicate with the IPSec server 208. Said in another way, an IPSec client is configured on the user's computer. The user initiates the IPSec client to communicate with the IPSec server 208, which then sets up a tunnel between the client 202 and the private network 206. Once a tunnel is set up by the IPSec server 208 with the client 202, the client 202 can access information or data within the private network 206 as if the client 202 is sitting within the private network 206. In this arrangement, the client 202 may also include any number of applications which may access the private network 206, such as an internal server 210.
One disadvantage of an IPSec arrangement is that each client has to be customized with IPSec client software in order to interface with the private network 206. In other words, the IPSec client software must be tailored to each client's machine. Accordingly, a client cannot access components of the internal server 206 without having customized software installed on their client machine. Thus, a user cannot access the private network 206 from any computer (e.g., such as a computer at an Internet café), but only a computer which is specially configured. Additionally, one may wish to not allow specific clients to access the complete resources in the private network 106. That is, restriction on particular data and/or servers within the private network may be desired. In one example, a business may wish to restrict a business partner to have access to only a subset of data within the private network.
FIG. 3 is a diagrammatic representation of a network 300 which includes an SSL-VPN (virtual private network) server 308. In this type of network, the client 302 may access resources on the private network 306 from any computer that supports SSL. In general, a browser of the client 306 makes an initial request for an initial web page to the SSL-VPN server 308. An SSL session then commences between the server 308 and client 302. This SSL session may include authentication of client 302.
After the SSL session completes, the user may then access links within the initial web page. However, prior to sending the initial web page to the client, the SSL-VPN server 308 has substituted URL's for each of the links embedded in the initial web page so that the links correspond to the SSL-VPN server 308. The links may have initially referenced the URL of internal server 310 of private network 306. However, the client 302 is not allowed to access internal server 310 of private network 306. Data on internal server 310 may only be accessed through SSL-VPN server 308. When the client 302 clicks on a link of the initial web page, the request is directed to the SSL-VPN server 308, which then may retrieve the appropriate web page from within the private network 306, e.g., from internal web server 310 and forward it to the client, (if the client is authorized to access the web page).
This arrangement has several disadvantages. For example, the SSL-VPN server 308 has to be configured to recursively substitute addresses for each web page link on each web page. As the number of clients increase, the number of substitutions increase significantly. Unfortunately, the performance of the SSL-VPN server 308 tends to degrade with increased numbers of clients.
In view of the above, there is a need for improved mechanisms for securely handling requests by a client for data from a private network.